1. Field of the Invention
The present invention relates to design verification in the digital computing field. More particularly, the present invention relates to a coverage analysis tool and method that monitors a simulation test on a digital design to detect and report interesting events and states achieved during the simulation.
2. Description of the Related Art
A digital design performs a finite number of logical functions or operations. For instance, a typical digital design such as a microprocessor might support four separate operations called addition (a), multiplication (m), subtraction (s), and division (d). Within each operation, different specific events may occur. For instance, addition of two negative numbers may occur, or addition of two positive numbers may occur.
A digital design will support many combinations of events where each type of specific event is called a state. In more complex designs, events may happen serially so that the number of states is increased. For instance, the operation sequence addition-multiplication-division (amd) is a different state than the operation sequence addition-multiplication-subtraction (ams). More states exist in the digital design when each a, m, s, and d operation supports various types of operands (i.e., positive, negative, and zero). Each permutation combining possible specific events results in a different state.
Exhaustive verification of modern digital designs such as microprocessors is virtually impossible because such designs may attain an almost incalculable number of states. A designer must therefore determine a sub-list of states that represent the most interesting states. The sub-list of states should include functional events, which are events that can be defined based on the specification of the design, and implementation events, which are specific to how the designer chose to implement the specification. While the sub-list of interesting states is not exhaustive, it usually provides a yardstick for measuring test coverage. To gain an adequate level of confidence that the design is functioning correctly, it is necessary to verify whether the design attains all of these interesting states during operation or simulation.
Verification of digital designs is usually done using a simulator. A simulator is a program that runs the design file of a digital design in order to recreate how the design would perform on a computer chip. A common method for generating test stimulus is to use a random, or directed random, test case generator. With random test case generation, the correctness of the design being simulated is established by having the results predicted automatically by some sort of reference model. The actual checking may take many forms, ranging from comparing the final results in memory to checking internal state cycle-by-cycle. There are major advantages to using random test case generation. Computer programs can generate test cases much faster than people can, so many more design states can be reached in the same amount of time using random test case generation. This is critically important for complex designs which need a reasonable time-to-market. Also, by introducing randomness, the verification engineer can think of a general set of tests that would hit interesting states, and let the computer generate all the special cases. In many cases, the random test generator ends up creating situations that a tester may not have thought to create.
One drawback to random test case generation is that it is difficult to know exactly what is being tested. Consequently, it is difficult to gain an adequate level of confidence that the design is attaining all of the required states determined by the designer to be interesting. A number of approaches have been used to determine when a design has been sufficiently verified using random test case generation. One method is to use statistical data from previous designs to predict the expected bug rate. This requires that the statistical data exist for the same style of design and the same test generation tool. Another method is to simply try as many different test strategies with the random test generator as one can think of, and then run them until the bug rate decreases. A third method is to use coverage analysis tools to quantify the percentage of the existing design states that have been hit.
Existing coverage analysis tools typically traverse the source code of the design to generate a list of unique states to be tracked. Since the resulting coverage data is based purely on the existing source code, the coverage data is very specific to the implementation of the design. There is no way to use the coverage data to evaluate functional coverage, or how much of the specification that details the functional requirements of the design has been tested. It can also be difficult to evaluate how many of the cases that have not been hit are actually interesting. And finally, current source-code generated coverage tools do not generate and track interesting combinations of states, so source-code generated data does not include data on interesting combinations of events.
The present invention introduces a method for evaluating coverage from either a functional or an implementation perspective, including combinatorial coverage. It provides an easy way to write a software monitor to identify an event or state in a design simulation and then log the information concerning attainment of the state into a database for further analysis. Designers can then analyze the database to determine if the simulation provides adequate coverage of a particular list of interesting events. If the simulation does not adequately cover certain events, the cause can then be investigated. The list of events monitored and reported into the database can be driven by the sub-list of events determined by the designer to be interesting.
One way that designers identify interesting combinatorial events is to take the cross product of two or more events. For example, designers typically want to verify design functionality for every possible combination of two back-to-back instructions. Likewise, designers will likely want to test all possible combinations of operands for an instruction. As designs become more complex and capable of executing more unique instructions with more types of operands, more interesting states can be expressed as a cross product of different events.
The assignee of the present invention, Intrinsity, Inc., has developed and patented a new logic design style called N-NARY Dynamic Logic (“NDL”). A new logic design style requires new coding techniques to verify the computer-aided design of the logic circuits and their constituent subcircuits, and NDL is no exception. NDL is a dynamic logic design style fully described in U.S. Pat. No. 6,069,49, titled “Method and Apparatus for a N-NARY Logic Circuit Using 1-of-N Signals”, which is incorporated by reference for all purposes and is referred to herein as “The N-NARY Patent.” NDL uses a multiphase clock scheme that self-synchronizes the logic flow, thus eliminating the need for static latches and registers and elaborate timing schemes. NDL synchronization is further described in detail in U.S. Pat. No. 6,118,304, entitled “Method and Apparatus for Logic Synchronization,” which is incorporated for all purposes and referred to herein as “the Logic Synchronization Patent.”
The simulation of NDL is fully described in the following copending patent applications: U.S. patent application Ser. No. 09/405,618, filed 24 Sep. 1999 (24.09.1999), titled “Software Modeling of Logic Signals Capable of Holding More Than Two Values”, and U.S. patent application Ser. No. 09/405,474, filed 24 Sep. 1999 (24.09.1999), titled “Four-State Simulation for Non-Binary Logic”, both of which are incorporated by reference for all purposes.
As described in further detail in the N-NARY patent, the N-NARY logic family supports a variety of signal encodings, including 1-of-4. In 1-of-4 encoding, four wires are used to indicate one of four possible values. In contrast, traditional static logic design uses two wires to indicate four values, as is demonstrated in Table 1. In Table 1, the A0 and A1 wires are used to indicate the four possible values for operand A: 00, 01, 10, and 11. Table 1 also shows the decimal value of an encoded 1-of-4 signal corresponding to the two-bit operand value, and the methodology by which the value is encoded using four wires.
TABLE 1N-NARY (1-of-4)Signal AN-NARY (1-of-4) Signal A2-bit operand valueDecimal Value1-of-4 wires assertedA1A0AA[3]A[2]A[1]A[0]0000001011001010201001131000
While “traditional” dual-rail dynamic logic also uses four wires to represent two bits, the dual-rail scheme always requires two wires to be asserted, whereas NDL only requires assertion of one wire, thus reducing power and signal noise. Other benefits of NDL over dual-rail dynamic logic are described in the N-NARY Patent. All signals in NDL, including 1-of-4, are of the 1-of-N form where N is any integer greater than one. More than one wire will never be asserted for a valid 1-of-N signal. Similarly, NDL requires that a high voltage be asserted on only one wire for all values, even the value for zero (0).
Any one NDL gate may comprise multiple inputs and/or outputs. In such a case, a variety of different N-NARY encodings may be employed. For instance, consider a gate that comprises two inputs and two outputs, where the inputs are a 1-of-4 signal and a 1-of-2 signal and the outputs comprise a 1-of-4 signal and a 1-of-3 signal. Variables such as P, Q, R, and S may be used to describe the encoding for these inputs and outputs. One may say that one input comprises 1-of-P encoding and the other comprises 1-of-Q encoding, wherein P equals two and Q equals four. Similarly, the variables R and S may be used to describe the outputs. One might say that one output comprises 1-of-R encoding and the other output comprises 1-of-S encoding, wherein R equals four and S equals 3. Through the use of these, and other, additional variables, it is possible to describe multiple 1-of-N signals used in NDL gates that comprise a variety of different encodings.
1-of-N signals used in NDL gates are named according to a signal naming convention that is fully described in a copending patent application, U.S. patent application Ser. No. 09/210,408, titled “Method and Apparatus for N-NARY Hardware Description Language”, which is incorporated by reference for all purposes and is referred to herein as “The Hardware Description Patent.” The signal naming convention identifies certain information that characterizes the signal, specifically information concerning 1-of-N degree, evaluation, and clock phase. For further details regarding the meaning and interpretation of the various fields in a signal name, the reader is encouraged to refer to the Hardware Description Patent. A typical name for a typical 1-of-N signal might be “disp_valid—4H2”, which indicates a 1-of-4 signal described as “disp_valid” th evaluates on the rising edge of the second clock phase. The present invention refers to signals using the signal naming convention as described in the Hardware Description Patent.